今天的兩個故事原本是分兩天寫，但後來發現我的故事多到塞不下30篇，就把一些比較短的合併了。

#強者我同事 #同事Y

【故事一：我不做寫程式以外的任何事情】

這個故事發生在我才剛加入到這個專案當 Tech Lead 的時候。

前 Tech Lead 兼 PM：「我們專案在下個周末要舉辦技術研討會，Y 你可以參加分享技術開發的部分嗎？」

同事 Y：「我不做寫程式以外的任何事情。 不要叫我做任何雜事。」

背景故事

同事 Y 本質上不是什麼壞人，他只是一個沒有社會化、但技術能力非常強的資深工程師。從面試到後續工作，他都一直死守著一個原則：不做寫程式以外的任何事情，也不信任技術能力不夠的TL。
這也是為什麼 前TL 常常跟他吵架，導致後面我這個菜鳥必須要塞在他們兩個中間當作潤滑劑。

寫程式以外的工作包含了寫技術文件、開會、教育訓練等。 最荒謬的是，主管明知道他的狀況，當初竟然還是決定錄取他。

只要有人要他做這些「雜事」，他就會很生氣地抱怨：不懂為什麼要做這些沒有意義的事。
這個堅持直接導致了幾個狀況：

• 他把自己完全封閉在純開發的世界裡，不去了解使用者真正想要的是什麼。每次他寫出來的系統我都很頭痛。
• 他不願意將任何技術細節記錄下來，知識無法傳承或其他人不能deputy。
• 他沒有辦法很好地跟團隊合作，橫向溝通成本極高。

最經典的是，他的組務月報總是只寫一句話：「系統開發和 debug。」（這有寫跟沒寫是一樣的，講過了也沒用）。

身為 Tech Lead 的我，接手後遇到的第一個難題竟然就是人的問題。
回頭看這整件事，最讓人毛骨悚然的，其實不是同事 Y 拒絕溝通，而是當年主管竟然默許了這個設定，然後把這顆「只要 Y 不在，系統就有機會沒人救得活」的定時炸彈，直接塞到我手裡。

難怪大家都說：所有的問題，都是人的問題。

【故事二：應該是使用者要來學習怎麼用吧？】

我：「Y，想跟你討論一下 UI 功能介面修正跟 API 設定調整。我覺得這是一個蠻合理的修改，調完後使用者能更直覺地找到功能，第三方公司接我們的 API 也會方便很多。」

Y同事：「為什麼要改？應該是使用者要來學習怎麼用我們的系統吧，而不是我們為了方便他們一直改啊？這樣是不是以後只要他們有需求，我們就要無底限一直配合？」

背景故事

事情是這樣的：有一天，介接我們 API 的合作公司傳Email詢問，能不能稍微調整一下某些參數設置。我評估後發現這要求非常合理、而且改動成本極低；幾乎是同一個時間，也有使用者反映系統某個關鍵功能有點難找。

身為 Tech Lead，我先思索了調整方案，並找 UI/UX 設計師確認過可行性，確認這能大幅提升產品體驗後，才拿去跟 Y 討論。
結果就收到了那句經典名言：「應該是使用者要學習怎麼用吧？」

開玩笑的。

身為工程師，想保護自己的工時、不想無意義地做隨興改動，這完全可以理解。但這中間其實存在資訊落差與思維差異：

1. 「被過濾掉的需求」你看不到

並不是所有來自使用者或客戶的要求我都會單單照收。事實上，身為 Tech Lead，我每天擋掉的奇葩需求比接進來的多太多了。只有經過層層評估、確認「改動成本低、效益高、邏輯合理」的需求，才會走到工程師面前。
但在底下的工程師視角裡，他們看不到背後被我砍掉的那 90% 需求，他們只會覺得：「怎麼又有新工作進來了？」 所以後來我就培養了定期跟大家sync的習慣，不要把資訊鎖在自己這邊，而是要讓大家知道目前的真實狀況。

2. 好的 UX 是引導，不是考驗智商
「使用者確實需要學習」，這句話沒錯，但好的 UI/UX 體驗是讓使用者不用思考就能順暢操作，而不是把功能藏在選單深處，搞得像在玩密室逃脫。明明功能做得很好，卻因為介面太難用而沒人發現，這對開發團隊來說其實非常可惜。

3. 開發模式的重新思考

專案偏向傳統的瀑布式開發（Waterfall），好不容易做完一大包，上線後才發現使用者用得很痛苦，回頭修改代價巨大。
這也讓我開始思考，團隊是否該逐步評估引進 Agile 或 Scrum 的可行性。透過小步快跑、提早拿到使用者回饋，才不會每次都在最後一刻為了要不要花大把時間去改而陷入無限痛苦深淵。

最後是靠我多次跟他1x1的會議，耐心地跟他說明我們為什麼要這麼做，好不容易讓他變得越來越社會化。
不然常常我都覺得我自己改就好了，我請你改是尊重你身為feature owner的角色，不然我也不需要找你還要面對你在那邊擺態給我看。
最近回去聊天的時候，他還在同一家公司，發現他這個現象目前好了很多，現在是一個優秀的資深工程師了呢！

我以前也覺得技術至上，反正只要讓他去做寫程式的工作就好了；但自從遇到他以後，我完全改觀了。
我寧願要一個技術沒這麼強的，但願意學習和願意溝通的人。